aelf技术点解读 | 跨链转账实现方式

跨链是当前区块链领域最火热的话题之一，由于链与链之间的天然隔离性以及链间数据交互的需求的急剧增加，跨链技术成为区块链底层环境重要的技术需求。践行区块链互操作性（Interoperability）的发展理念也被认为是当下区块链技术重要的探索方向。aelf作为自主研发的跨链项目，具有一套完整的跨链解决方案，本文将具体介绍aelf在跨链方面的重要特性和设计理念。

跨链简述

进入主题之前，我们先了解一下什么是跨链。A链上产生的数据或行为以某种形式应用在B链上，这个过程就称为跨链。而互操作性是对上述跨链过程的一个属性化描述。为了便于理解，下文将统一使用“跨链”来表示此过程和属性。目前跨链应用场景包括但不限于跨链转账、跨链资产交换和链的扩容等。跨链的实现按照应用协议兼容性可分为两大类：第一类是在可互相兼容应用协议的区块链之间实现跨链， 第二类是在应用协议无法兼容的区块链之间实现跨链。

跨链的定义是宽泛的，并没有严格的跨链标准，但是所有跨链解决方案都是为了突破链间隔离、实现链间数据交互而设计。那么是否可以完全摒弃链间隔离？当然不是。除了协议不兼容导致天然隔离的区块链项目之外，链间隔离更重要的一个意义在于实现资源隔离。资源隔离让不同分布式应用场景运行在不同的链上，不同应用场景之间互不影响，跨链的过程就是在最大程度地确保资源隔离的前提下，实现链间数据关联交互，这也是多链平台aelf的设计理念。

aelf 多链结构

aelf是一个基于多级主-侧链体系的多链结构网络。首先对aelf的多链结构进行解析：一主链、多侧链、多层级。图1表示的是链与链之间的从属关系，各个侧链都是基于上一级链创建出来的，下文将用父链和子链表达这种结构关系。该结构关系意味着每一条链都可创建自己的子链。aelf的多链结构的优势不仅在于可实现不同应用场景的链间隔离，同时可利用链间从属关系创建更多子链以扩展应用场景。

图1

aelf的多链结构是基于一链一场景这一核心理念设计的。主链仅支持共识模块，经济系统模块和跨链模块等系统合约，aelf社区并不建议在主链上部署过多的场景，而是将丰富多样的场景部署到侧链。每条侧链的场景复杂度都是O(1)，可将不同场景的DApp部署在不同的侧链上。基于这样的设计理念，aelf实现了前文提到的资源隔离。目前一些公链经常遇到一个问题：单个爆款应用即可能导致整条链堵塞，导致短时间内链上交易费提高数倍，根本原因就在于所有应用和资产都部署在同一条链上，但是一链一场景的设计机制可有效避免这个问题，一条链的堵塞并不会影响到其他链的正常运行。

链的生命周期

主链是aelf生态系统的中枢，也是整个生态启动运行的第一条链。主链上部署了若干系统合约，其他具体的应用场景需申请创建侧链并在侧链上进行部署。创建侧链时需要向社区提出申请，同时需抵押一定的ELF token，并提供索引费用和相关资源token使用计划等信息，等待社区审批通过。侧链创建申请通过后，即可创建侧链并启动运行，该侧链也随即被主链索引（有关索引的内容将在后文介绍）。侧链申请通过后可以对该链进行索引费充值，以保证主链提供稳定索引服务。如需停止对该侧链的索引时，同样需向社区提出申请，审批通过后主链正式停止对该侧链的索引。基于侧链创建下级子链的过程和上述过程一致，此时侧链将充当父链的角色。

跨链索引

索引是指按照定义好的结构从某条链将数据传递给其他链。跨链索引是实现任何跨链功能的前提。aelf采用“联合挖矿”的理念，即由矿工自主完成索引过程。aelf这样的设计能够有效解决两个问题：

• 第一个问题是某条链是否可以被信任。这是在跨链过程存在的一个常见问题，只有有效运行的区块链才被认为可以安全索引。aelf采用的“联合挖矿”理念从根本上解决了这个问题，可兼顾到主链与侧链的正常运行，而不需要对链自身设计冗余的信任机制。

• 第二个问题是数据索引是否去中心化。这是跨链过程中一个比较棘手的问题。如何保证去中心化是跨链解决方案的一大挑战。aelf的策略是矿工自主完成索引，并且索引数据作为普通数据参与共识等验证过程，因此aelf的索引过程和数据源是完全去中心化的，可最大程度地保障索引数据的安全。

aelf跨链索引分为两部分：父链索引子链和子链索引父链：

• 父链从子链获取数据。父链对其需要索引的子链请求数据，如图2示，子链将区块内的Transaction status merkle tree root传递给主链。

• 父链将索引的所有子链数据进行处理，生成Merkle tree，并存储在链内部， 如图3示。至此，该子链区块即已被父链索引，只需等待该数据得到网络的确认。

• 子链索引父链区块，即从父链请求数据。如图4示，子链返回的数据：1. 已计算好的merkle tree root; 2. Merkle path。

上述步骤包含了父链索引子链区块及子链再索引父链区块的完整过程。这里有一点需要强调的是只有不可逆转的区块才能被其他链索引。这是因为区块链是去中心化的分布式账本，数据在被确认前是可能被逆转的，只有被确认成为不可逆转的数据才是可信的，这样可以有效的保护跨链的安全性，确保有足够多的节点处于相同的状态，避免跨链数据对本链的影响。

图 2

图 3

图 4

跨链验证

跨链验证直观上理解为在A链上验证B链上发生的事。aelf多链结构的设计理念是一链一场景，并不是所有链之间都有联系。链与链之间的验证关系也符合场景部署相关的原则，具体如下：

• 父链与子链之间可以相互验证

• 同级子链（兄弟链）之间可以相互验证

• 其他关系的链之间不可以相互验证

aelf 应用的是常见的的数据结构：默克尔树。上述索引过程也提到过这个数据结构，它是一个普通的树的结构，叶子结点包含某些特定数据进行哈希运算所得结果值，再由叶子结点向上两两进行Hash运算直到根节点。在这里aelf使用的是SHA256的加密算法。

图 5

之所以选择默克尔树是因为在于仅需付出很小的成本即可完成上述过程。如图6示，提取树中红色叶子结点到根节点的计算路径，设为Merkle Path。Merkle Path可以很方便地从树里提取出来，如图6中的绿色节点所示。上文提到的索引过程中的Merkle tree root 是一个32字节的定长数据结构，而Merkle path 也仅需付出 log(n)的空间复杂度，这极大的降低了跨链数据传输负载压力，保障跨链效率。

这棵树的结构和SHA256算法共同确保了这样的特性：通过根节点的一致性可以确保整棵树的正确性。跨链验证也是基于这样的特性进行设计。根据默克尔树的特性，仅利用叶子结点和提取出来的Merkle Path就可以计算出最终的黄色根节点。在跨链验证过程中，只需要利用Merkle Path进行一次从叶子结点到根节点的计算，即可验证数据准确性，时间复杂度 log(n)，确保验证效率。

利用上述结构可以高效完成数据存在性证明，从而实现跨链验证。存在性证明是aelf跨链机制的核心。aelf跨链模块并不局限于某一项特定的应用场景，而是利用存在性证明来提供一个开发跨链应用的高效平台。基于存在性证明，aelf在未来可以发掘、实现更多的应用场景。

图 6

总结

aelf致力于通过提供可行的跨链解决方案来实现去中心化跨链平台的构建。基于“一链一场景”的设计理念，aelf跨链机制可高效安全地实现跨链数据交互，同时可确保链间资源的有效隔离。由主链出块节点提供索引服务，可确保其去中心化程度；索引数据负载低，可确保跨链高效；只有不可逆转的区块才能被其他链索引的机规则， 则保障了跨链的安全性；经典的Merkle Proof验证方法，则可保障跨链的验证效率。